BATTLE  LABS: 

WHAT  ARE  THEY, 
WHERE  ARE  THEY  GOING? 
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Battle  Labs  serve  as  a  mechanism  for  assessing  ideas  and  capabiiities  provided  by  ad¬ 
vanced  technology.  More  than  this,  however,  Battle  Labs  represent  a  revolution  in  global 
thinking,  testing  by  computer  simulation,  and  streamlined  acquisition.  This  paper  ex- 
piains  what  Battie  Labs  are  and  what  they  wiii  be  used  for,  now  and  in  the  future. 


The  Army’s  leadership  initiated  the 
Louisiana  Maneuvers  and  the 
TRADOC  Battle  Labs  to  reshape 
the  service  for  the  post-Cold  War  era 
(Singley,  1993)  (see  Figure  1). 

The  Louisiana  Maneuvers  (LAM)  are 
used  to  study  battlefield  capabilities  and 
other  preparedness  issues  using  a  mix  of 
real  and  simulated  forces.  The  Army  lead¬ 
ership  use  the  LAM  to  make  decisions 
about  doctrine,  force  mix,  force  compo¬ 
sition,  and  other  areas  involving  funda¬ 
mental  change  (Ross,  1993).  They  are  also 
used  to  evaluate  the  Army’s  ability  to  pro¬ 
vide  ready  forces  in  a  timely  manner  to 
meet  several  force-projection  scenarios 
(Goodman,  1992).  The  LAM  use  ad¬ 
vanced  simulation  technologies  to  enable 
remote  units  to  participate  in  war  games 
and  test  all  phases  of  Army  operations 
(Goodman,  1992).  Advanced  simulation 


technology  is  the  key  to  the  LAM’s  suc¬ 
cess  in  helping  the  Army  leadership  visu¬ 
alize  and  understand  the  impact  of  evolv¬ 
ing  equipment  and  doctrinal  changes  on 
battlefield  performance  (Ross,  1993). 
Simulations  also  avoid  putting  large  num¬ 
bers  of  troops  in  the  field  to  train  battle 
staffs  and  test  new  doctrine,  plans,  equip¬ 
ment,  and  ideas.  The  LAM  serve  as  an 
Army  process  and  tool,  supported  by 
TRADOC  Battle  Labs,  and  focused  on 
warfighting  modernization  and  policy 
making  (Singley,  1993). 

In  reshaping  itself  into  a  smaller,  con¬ 
tingency-oriented,  power  projection  force, 
the  Army’s  imperative  is  to  maintain  its 
technological  superiority  (Franks  and 
Ross,  1993).  The  TRADOC  Battle  Labs 
play  a  part  in  this  reshaping  process  and 
provide  a  means  for  streamlii 
teriel  acquisition  process. 
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The  Battle  Labs  serve  as  a  mechanism 
for  assessing  ideas  and  capabilities  evolv¬ 
ing  from  advanced  technology  (Franks 
and  Ross,  1993).  Rather  than  a  single 
place  or  set  of  resources.  Battle  Labs  rep¬ 
resent  a  harnessing  of  brain  power  com¬ 
mitted  to  preparing  the  Army  for  the  next 
war  (Slear,  1992).  The  objective  of  each 
Battle  Lab  is  to  determine  the  potential 
military  value  offered  by  any  new,  ‘leap- 
ahead’  technology  early  in  the  acquisition 
process.  The  Army  focuses  on  six  specific 
battlefield  dynamics  and  each  is  repre¬ 
sented  by  a  Battle  Lab  electronically 
linked  to  its  counterparts,  allowing  the 
Army  to  cross  any  functional  lines  and  tap 
into  emerging  technologies  (Slear,  1992). 

A  Revoiution  in  Thinking 


The  Battle  Labs  concept  (Figure  2)  is  a 
revolution  in  global  thinking,  test  by  com¬ 
puter  simulation,  and  streamlined  acqui¬ 
sition  (Slear,  1 992).  Battle  Labs  are  a  new 
way  of  doing  business  (Franks,  1 993)  and 
will  institutionalize  a  new  way  of  think- 
ing-a  ‘paradigm  shift’-guided  by  coop¬ 
eration  and  integration  (Slear,  1992).  They 
will  serve  as  focal  points  for  examining 
the  impact  of  the  latest  battlefield  organi¬ 
zation,  tactics,  doctrine,  and  technologi¬ 
cal  capabilities  on  the  battlefield  of  the 
future  (Franks  and  Ross,  1993). 

The  simulation  capability  harnessed 
through  the  Battle  Labs  is  evolving  into 


virtual  reality  (Slear,  1992).  The  Battle 
Labs  allow  the  Army  to  evaluate  the 
battlefield  performance  of  new  technol¬ 
ogy  by  using  simulations  or  prototypes 
(Roos,  1992).  This  is  accomplished  via  a 
network  of  computer  simulations  connect¬ 
ing  the  six  Battle  Labs,  known  as  Distrib¬ 
uted  Interactive  Simulation  (DIS),  which 
serves  as  the  foundation  for  the  LAM  ex¬ 
ercises.  These  simulations  generally  fall 
into  one  of  three  categories:  live,  construc¬ 
tive,  or  virtual  (Ross,  1993). 

Live  simulations  include  those  exer¬ 
cises  conducted  by  soldiers  on  field  exer¬ 
cises.  Constructive  simulations  are  com¬ 
puterized  wargaming  models  with  the 
battlefield  in  the  computer.  They  use  pro¬ 
grammed  input  to  ‘fight’  battles  on  com¬ 
puters  with  models  which  are  interactive 
and  put  soldiers  in  the  loop  to  react  to 
battlefield  situations.  Virtual  simulations 
are  trainers  such  as  flight  simulators  or 
tank  simulators  that  create  a  realistic  syn¬ 
thetic  environment  to  train  and  test  sol¬ 
diers. 

Simulations  from  the  Battle  Labs  rep¬ 
resent  reality  in  a  highly  believable  way, 
whether  simulating  theaters  of  war  or  fac¬ 
tories  and  their  manufacturing  processes 
(Franks  and  Ross,  1993).  The  DIS  trans¬ 
mits  situational  awareness  data  to  maneu¬ 
ver  units  and  the  Battle  Labs  (Franks, 
1993)  and  creates  a  synthetic,  virtual  rep¬ 
resentation  of  the  battlefield  by  connect¬ 
ing  the  separate  simulations  from  multiple 
locations  over  the  Defense  Simulation 
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figure  1.  Battle  Labs  (BTL)/Louisiana  Maneuvers  (LAM)  (Changing  the  Process) 
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Figure  2.  Battle  Lab  Comept 


Internet  (DSI).  This  connection  of  simu¬ 
lations  forms  a  ‘seamless  integration’ 
(Lang,  1992). 

The  Army  uses  this  synthetic  environ¬ 
ment  to  test  and  evaluate  the  impact  on 
overall  battlefield  performance  of  new  and 
existing  weapon  systems,  technology  in¬ 
sertions  into  existing  weapon  systems,  or 
the  tactical  deployment  and  logistical  sup¬ 
port  of  weapon  systems  (Ross,  1993).  The 
DIS  allows  for  the  practice  of  warfighting 
skills  and  the  evaluation  of  weapon  sys¬ 
tem  performance  when  cost,  safety,  envi¬ 
ronmental,  or  political  constraints  prohibit 
actual  field  tests  and  training  (Ross,  1993). 

As  General  Gordon  R.  Sullivan,  Army 
Chief  of  Staff,  recently  stated: 


The  most  promising  technologies 
will  be  tested  by  real  soldiers,  first 
in  reconfigurable  crew  stations,  then 
in  full-scale  simulators.  Final  de¬ 
signs,  production,  and  assembly 
steps  are  also  simulated  in  virtual 
factories  before  actual  prototypes  are 
made.  Then  the  actual  and  virtual 
prototypes  are  exercised  simulta¬ 
neously  to  discover  potential  prob¬ 
lems  before  production  begins 
(Binder,  1993). 

Gen.  Sullivan  also  stated: 

(T)here  is  a  great  deal  of  frustration 
with  the  cold  war  acquisition  system. 
It  served  us  well,  but  it  is  inappro- 
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priate  to  the  current  threat  environ¬ 
ment,  technology,  and  resource  en¬ 
vironments.  It  is  very  much  a  linear 
system — a  system  of  discrete  little 
boxes — and  what  we  require  now  is 
a  nonlinear  system,  a  system  with 
connectivity,  not  boxes.  The  Army 
must  change  to  survive  and  grow. 
The  technological  possibilities  are 
immense  and  could  become  over¬ 
whelming  without  a  mechanism  that 
allows  us  to  assess  the  possibilities 
and  control  the  pace  of  change.  That 
mechanism  is  the  Louisiana  Maneu¬ 
vers  (Binder,  1993). 

Streamlining  the  System 


A  look  at  the  current  status  of  our 
weapon  systems  and  the  acquisition  pro¬ 
cess  that  generates  them  shows  that  we 
now  have  very  complex,  software-driven 
weapons  systems,  many  of  which  still  do 
not  meet  requirements  after  10  years  of 
concept  definition  and  development.  This 
condition  was  recently  restated  by  a  De¬ 
partment  of  Defense  (DoD)  study  group 
investigating  problems  in  testing  (Under 
Secretary  of  Defense,  1994).  The  primary 
findings  were: 

1.  The  requirements  generation  and 
management  process  led  to  unreal¬ 
istic  operational  requirements. 

2.  Program  Development  Testing  and 
Evaluation  (DT&E)  was  not  suffi¬ 
ciently  robust  to  confidently  enter 
Operational  Testing  and  Evaluation 
(OT&E)  phase  of  testing. 

3.  System  boundaries  were  not  suffi¬ 


ciently  defined. 

Several  contradictions  in  our  current 
acquisition  process  are  made  apparent  in 
the  summary  in  Figure  3.  Our  weapons 
systems  are  very  complex,  yet  we  insist 
on  low  bid  solutions.  This  can  be  the  ‘sting 
of  death’  for  a  program:  Inexpensive  but 
inexperienced  contractors  may  prove  un¬ 
able  to  meet  our  engineering  development 
requirements  due  to  their  lack  of  exper¬ 
tise  or  their  underestimation  of  the  effort 
necessary;  alternatively,  the  program  may 
amass  overruns  trying  to  overcome  a  more 
sophisticated  contractor’s  lowball,  ‘buy- 
in’  proposal. 

Our  acquisition  system  is  not  designed 
to  succeed  by  encouraging  innovative 
flexibility;  perhaps  that  is  why  there  are 
so  few  acquisition  success  stories  in  the 
1990s.  Another  factor:  rapidly  changing 
doctrine  that  outpaces  the  acquisition  pro¬ 
cesses.  Is  it  any  wonder  that  the  Army’s 
leadership  is  seeking  a  ‘paradigm  shift’ 
when  we  read  that  soldiers  are  denied  the 
improved  systems  they  want  and  are 
forced  to  accept  other  systems  they  nei¬ 
ther  want  nor  need? 

Software  is  the  critical  path  of  system 
development,  and  system  performance 
depends  on  it.  It  has  become  the  ‘Achil¬ 
les  Heel’  of  weapons  development 
(Kitfield,  1989).  Figure  4  reflects  the  im¬ 
mense,  rapidly  increasing  market  cost  of 
DoD  software  as  compared  to  the  rela¬ 
tively  flat  cost  projections  for  computer 
hardware  (Defense  Systems  Management 
College,  Unk.).  Why  doesn’t  DoD  con¬ 
trol  this  cost?  The  answer  is  easy:  DoD 
represents  only  15  percent  of  the  total 
market  for  software  (see  Figure  5) 
(Huskins,  1994).  It  is,  overwhelmingly,  a 
civilian  market  not  amenable  to  regula- 
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tion  by  DoD. 

The  Army  estimates  that  65  percent  of 
the  money  it  supposedly  spends  on  soft¬ 
ware  is  actually  paid  to  define  system  re¬ 
quirements  (Kitfield,  1989).  The  state-of- 
the-art  technology  driving  these  require¬ 
ments  at  the  beginning  of  development  is 
often  obsolete  before  the  system  is  fielded 
(Defense  Systems  Management  College, 
Unk.),  a  fact  rarely  considered  in  award¬ 
ing  contracts  to  a  low  bidder  already  at 
his  technical  limits.  Moreover,  a  program 
manager  that  spends  precious  dollars  on 
software  tools  and  reusable  software  racks 
up  an  increased  cost  that  may  put  his  pro¬ 
gram  at  risk.  This  low  bid  mindset  also 
ignores  the  peculiarities  of  the  software 
market,  where  the  product  is  strictly  con¬ 
ceptual  and  the  means  to  realize  it  are 
largely  intellectual  (Kitfield,  1989). 


As  support  for  the  Battle  Labs  — ^from 
the  grass  roots  as  well  as  from  the  leader¬ 
ship — has  made  obvious,  the  need  for 
concurrent  engineering  is  now  apparent 
and  has  started  to  dismantle  the  walls  of 
compartmentalization.  The  focus  on  the 
testing  and  tester  involvement  in  devel¬ 
opment  is  changing  as  shown  in  Figure  6 
(Franks,  1993).  The  acceptance  of  testing 
and  evaluations  conducted  in  a  virtual 
environment,  on  a  synthetic  battlefield, 
will  lead  to  significant  savings  as  much 
of  the  current  field  testing  is  eliminated 
(Ross,  1993).  The  realization  that  soft¬ 
ware,  not  hardware,  is  the  driver  is  em¬ 
bodied  in  the  Battle  Lab  philosophy  of 
making  engineering  development  and  test 
possible  earlier  on  (well  into  concept  de¬ 
velopment  and  definition),  as  well  as  get¬ 
ting  everybody  involved  through  devel- 
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Figure  6.  Changing  Focus  on  ODT&E 


opment  teaming.  Success  in  reshaping  the 
Army  requires  that  only  the  most  cost-ef¬ 
fective  advanced  technologies  (i.e.,  those 
most  likely  to  be  found  in  software)  are 
pursued  to  ensure  a  technological  edge. 
Along  with  technology,  the  cycle  time 
from  laboratory  to  prototype  and  produc¬ 
tion  must  be  reduced;  otherwise,  the  ad¬ 
vantage  of  developing  a  leading  edge 
technology  is  lost  (Franks  and  Ross, 
1993).  Taken  together,  these  points  reflect 
an  understanding  that  early  expenditures 
provide  the  greatest  leverage  in  prevent¬ 
ing  errors.  Up  to  70  percent  of  errors  are 
detected  early,  when  error  correction  is 
cheapest  (MaCabe  and  Schulmeyer, 
1987). 

Typically,  almost  90  percent  of  a 


weapon  system’s  cost  is  decided  before 
entering  development  (Figure  A  of  Fig¬ 
ure  7);  it  would  be  a  mistake  wait  for  er¬ 
rors  in  the  decision-making  process  to 
appear  in  the  costly  operational  test,  pro¬ 
duction,  and  deployment  phases  (Singley, 
1993).  We  are,  nevertheless,  failing  to 
detect  errors  before  making  decisions  af¬ 
fecting  what  will  amount  to  60  percent  of 
the  costs  for  our  weapon  systems  through¬ 
out  their  life  cycles  (Figure  C  of  Figure 

7). 

As  Gen.  Sullivan  has  stated: 

(T)he  new  focus  is  that  we  are  push¬ 
ing  armor,  infantry,  the  entire  com¬ 
bined  arms  team  into  the  digitized 
world  where  most  weapon  improve- 
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ments  are  through  software  revi¬ 
sions.  While  the  core  of  the  20th  cen¬ 
tury  land  warfare  is  the  tank,  the  core 
of  the  21st  century  is  the  computer. 
Simulations  are  used  to  maintain 
readiness  in  a  military  force  in  which 
downsiz-ing  and  tight  budgets  are 
prime  considerations  for  the  foresee¬ 
able  future  (Binder,  1993). 

The  way  is  identified  and  the  pressures 
are  great  (Figure  8).  What  is  needed  are 
the  ‘paradigm  pioneers’  to  lay  the  road. 

The  use  of  Battle  Labs  is  a  needed 
change  to  keep  pace  in  this  rapidly  devel¬ 
oping  information  age,  but  to  succeed  it 
will  require  visionary  leadership  as  well 
as  good  management  skills.  Albeit  with 


growing  pains.  Battle  Labs  are  here  to 
stay. 
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